1. Field of the Invention
The invention relates to a method and a network device for handling authentication requests, and is in particular related to the problem of Denial-of-Service attacks caused by fake authentication request.
2. Description of the related art
Denial-of-Service (DoS) attacks may be a problem in almost any kind of networks. In the following, this problem is described using Unlicensed Mobile Access (UMA) as an example. The 3rd Generation Partnership Project's (3GPP) Wireless Local Area Network (WLAN) Interworking is used as another example.
Unlicensed Mobile Access (UMA) technology provides access to GSM and GPRS mobile services over unlicensed spectrum technologies, including Bluetooth and IEEE 802.11. UMA specifications are available at “http://www.umatechnology.org”.
In the following, the basic architecture of UMA is described by referring to FIG. 1. As illustrated, a terminal, e.g., a mobile station MS 1 obtains access to a core mobile network 3 via an Unlicensed Mobile Access Network (UMAN) 2. In detail, the mobile station 1 is connected to an Access Point (AP) 21, for example via Bluetooth or Wireless Local Area Network (WLAN, IEEE 802.11), as described above. A connection between the AP 21 and an UMA network controller (UNC) 23 is provided via a broadband Interned Protocol (IP) network 22. It is noted that the specific UMA features apply basically only for the MS 1 and the UNC 23, so that for the AP 21 any generic AP may be used.
The UNC provides functions which are basically equivalent to that of a Radio Access Network (RAN) base station controller. It comprises a Security Gateway (SGW) 231 that terminates secure remote access tunnels from the MS, providing mutual authentication, encryption and data integrity for signalling, voice and data traffic.
In more detail, the terminal 1 accesses the UMA service over an IPsec (Internet Protocol Security) VPN (Virtual Private Network) tunnel which is provided via the AP 21 and the broadband IP network 22. The subscriber is authenticated using the Internet Key Exchange version 2 (IKEv2) protocol and the Extensible Authentication Protocol method for GSM Subscriber Identity Modules (EAP-SIM). The UMA network controller (UNC), in detail the SGW, operates as an Extensible Authentication Protocol (EAP) authenticator, and forwards the EAP packets between the terminal and an AAA (Authentication, Authorisation and Accounting) server 31 of the core mobile network 5. The EAP-SIM server functionality is implemented in the AAA server. In order to run EAP-SIM authentication, the EAP-SIM server needs to be able to obtain GSM triplets (RAND random challenge, Kc key, SRES response) from the Authentication Centre (AuC) which is associated with the GSM Home Location Register (HLR).
The Extensible Authentication Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) is another EAP method based on cellular authentication. In the future, EAP-AKA may be used also in the UMA system for subscriber authentication.
In the following, the EAP-SIM and EAP-AKA authentication exchanges and the identity format are described in more detail. The EAP-SIM and EAP-AKA protocols support two types of authentication exchanges, namely the full authentication exchange and the fast re-authentication exchange. The full authentication exchange makes use of the GSM triplets or 3G authentication vectors, and the (U)SIM card. The fast re-authentication exchange is based on the keying material derived on a previous full authentication exchange. To run the fast re-authentication exchange, the EAP server does not need to contact the HLR/AuC.
In the beginning of an EAP-SIM or EAP-AKA authentication exchange, the terminal sends a peer identity to the network. The identity is of the Network Access Identifier (NAI) format (“username@realm”). There are three types of usernames in EAP-SIM and EAP-AKA peer identities:
(1) Permanent Usernames.
For example, 1123456789098765@myoperator.com might be a valid permanent identity. In this example, 1123456789098765 is the permanent username. In the UMA environment, the permanent username is derived from the International Mobile Subscriber Identity (IMSI).
(2) Pseudonym Usernames.
For example, 3s7ah6n9q@myoperator.com might be a valid pseudonym identity. In this example, 3s7ah6n9q is the pseudonym username. Pseudonym usernames are used in lieu of the permanent username for privacy reasons, in order to hide the permanent username from observers. When the optional identity privacy support is not used, the non-pseudonym permanent identity is used on full authentication.
(3) Fast Re-authentication Usernames.
For example, 53953754@myoperator.com might be a valid fast re-authentication identity. In this case, 53953754 is the fast re-authentication username. Unlike permanent usernames and pseudonym usernames, fast re-authentication usernames are one-time identifiers, which are not re-used across EAP exchanges.
The first two types of identities are only used on full authentication and the last one only on fast re-authentication.
In the following, the generation of pseudonyms and fast re-authentication identities is described.
The first EAP exchange initiated by a terminal always uses the permanent username derived from the IMSI (International Mobile Subscriber Identity). The EAP server generates the pseudonym usernames and re-authentication usernames and sends them to the terminal, in an encrypted format, as part of the EAP exchange. The terminal can then use the received identities in subsequent EAP exchanges.
The format of the pseudonym identity and the fast re-authentication identity is opaque to the terminal—the terminal does not need to care how the server composes these identities. The terminal only uses the received identity string as-is. The fast re-authentication identity contains both a username portion and a realm name portion.
The 3GPP Technical Specification 33.234, “3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; 3G Security; Wireless Local Area Network (WLAN) Interworking Security (Release 6)” (V 6.4.0, 2005-03), specifies the usage of the EAP-SIM and EAP-AKA protocols in the 3GPP environment. TS 33.234 specifies how the server generates pseudonyms and fast re-authentication identities. The identities include the IMSI of the subscriber, encrypted using Advanced Encryption Standard (AES) in Electronic Codebook (ECB) mode of operation with 128-bit keys. The temporary identity generation is described in the following, which is basically an excerpt of Section 6.4.1 of TS 33.234, by referring to FIGS. 2A and 2B.
In order to encrypt with AES in ECB mode, it is necessary that the length of the clear text is a multiple of 16 octets. This clear text is formed as follows:    1. A Compressed IMSI is created utilising 4 bits to represent each digit of the IMSI. According to TS 23.003, the length of the IMSI is not more than 15 digits (numerical characters, 0 through 9). The length of the Compressed IMSI shall be 64 bits (8 octets), and the most significant bits shall be padded by setting all the bits to 1.For example:    IMSI=214070123456789    (MCC=214; MNC=07; MSIN=0123456789)    Compressed IMSI=0xF2 0x14 0x07 0x01 0x23 0x45 0x67 0x89
Observe that, at reception of a temporary identity, it is easy to remove the padding of the Compressed IMSI as none of the IMSI digits will be represented with 4 bits set to 1. Moreover, a sanity check should be done at reception of a temporary identity, by checking that the padding, the MCC and the MNC are correct, and that all characters are digits.    2. A Padded IMSI is created by concatenating an 8-octet random number to the Compressed IMSI.
A 128-bit secret key, Kpseu, is used for the encryption. The same secret key must be configured at all the WLAN AAA servers in the operator network so that any WLAN AAA server can obtain the permanent identity from a temporary identity generated at any other WLAN AAA server (see section 6.4.2 of TS 33.234). FIG. 2A summarises how the Encrypted IMSI is obtained.
Once the Encrypted IMSI has been generated, the following fields are concatenated, as is also illustrated in FIG. 2B:                Encrypted IMSI, so that a AAA server can later obtain the IMSI from the temporary identity.        Key Indicator, so that the AAA server that receives the temporary identity can locate the appropriate key to de-encrypt the Encrypted IMSI (see section 6.4.2 of TS 33.234).        Temporary identity Tag, used to mark the identity as temporary pseudonym or re-authentication identity. The tag should be different for identities generated for EAP-SIM and for EAP-AKA.        
The Temporary Identity Tag is necessary so that when a WLAN AAA receives a user identity it can determine whether to process it as a permanent or a temporary user identity. Moreover, according to EAP-SIM/AKA specifications, when the Authenticator node (i.e. the AAA server) receives a temporary user identity which is not able to map to a permanent user identity, then the permanent user identity(if the AAA server recognizes it as a pseudonym) or a full authentication identity (if the AAA server recognizes it as a re-authentication id) shall be requested from the WLAN client. As the procedure to request the permanent user identity is different in EAP-SIM and EAP-AKA, the Temporary Identity Tag must be different for EAP-SIM pseudonyms or re-authentication identities and for EAP-AKA pseudonyms or re-authentication identities, so that the AAA can determine which procedure to follow.
The last step in the generation of the temporary identities consists on converting the concatenation above to a printable string using the BASE64 method described in section 4.3.2.4 of RFC 1421 (“Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures” by J. Linn, February 1993). With this mechanism, each 6-bit group is used as an index into an array of 64 printable characters. As the length of the concatenation is 138 bits, the length of the resulting temporary identity is 23 characters, and no padding is necessary. Observe that the length of the Temporary identity Tag has been chosen to be 6 bits, so that it directly translates into one printable character after applying the transformation. Therefore, at reception of a user identity, the AAA server can recognise that it is a temporary identity for EAP-SIM or a temporary identity for EAP-AKA without performing any reverse transformation (i.e. without translating any printable character into the corresponding 6 bits).
Hence, in this way the pseudonyms and fast re-authentication identities are generated according to TS 33.234.
The UMA system may be exposed to so-called Denial-of-Service (DoS) attacks, as described above. In these attacks, the attacker attempts to bring down-network nodes by sending a very large amount of authentication-related messages. If the processing capacity of some network element is exceeded, the network element may not be able to server the legitimate authentication requests from ordinary terminals. Hence, the attacker may manage to deny the UMA service from legitimate users.
By sending IKEv2 and EAP-SIM or EAP-AKA messages to the UNC, a DoS attacker may try to bring down the UMA controller, AAA elements, such as intermediate AAA proxies or the AAA server, and even elements in the cellular network such as the HLR or the AuC. If the DoS attack brings down a HLR or an AuC, then not only the UMA service but also the GSM or UMTS service may be affected.
A general technique to resist DoS attacks is to apply rate limits. That is, a network control element may limit the rate at which authentication attempts are accepted for example from a given IP address.
DoS protection is discussed in Section 11.4 of the EAP-SIM document “Extensible Authentication Protocol Method for GSM Subscriber Identity Modules (EAP-SIM)” by H. Haverinen and J. Salowey, December, 2004 (http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-16.txt). In particular, the document specifies that the EAP-SIM server implementation should take DoS attacks into account and should take steps to limit the traffic that it generates towards the AuC, preventing the attacker from flooding the AuC and from extending the denial of service attack from EAP-SIM to other users of the AuC.
There are other general DoS resistance techniques, such as the cookie support in IKEv2 or client puzzles that are used in some protocols to make it harder to mount DoS attacks. Since the EAP-SIM and EAP-AKA protocols do not include cookies or client puzzles, they cannot be applied to the UMA environment.
Thus, there is a need to further improve security against DoS attacks.
It is noted that the problem described above does not only occur in connection with UMA, but can occur in all kind of networks requiring some kind of authentication. The problem was only identified in connection with UMA.
Another example where the same problem may occur is the 3GPP WLAN interworking environment. 3GPP has specified six WLAN interworking scenarios in Technical Report 22.934, “Feasibility study on 3GPP system to Wireless Local Area Network (WLAN) interworking (Release 6)”. EAP-SIM and EAP-AKA authentication are used in scenarios 2 and 3. They are briefly summarized here.
Scenario 2 is also called “WLAN Direct IP Access” in the 3GPP specifications. It refers to basic network access authentication and IP access at WLAN hotspots. One of the main technical features of this scenario is SIM and USIM based authentication using EAP-SIM and EAP-AKA protocols. In 802.11 networks, the EAP-SIM or EAP-AKA protocols are transported over the WLAN interface using the IEEE 802.1x standard for port based network access control. This protocol is used as a part of the WiFi Protected Access (WPA) specifications. The WLAN Access Point operates as an EAP Authenticator and relays EAP requests and responses between the terminal and an AAA network. The EAP server resides at the home network and operates similarly as in the UMA case which is described above.
Scenario 3 is also known as “WLAN 3GPP IP Access” in the 3GPP specifications. Since WLAN hotspots cannot always considered as trusted networks, the WLAN 3GPP IP Access specifies how a Virtual Private Network (VPN) tunnel can be established between the terminal and a VPN gateway, which is hosted by the operator. The VPN gateway is known as the Packet Data Gateway (PDG) in the 3GPP specifications. Scenario 3 technology does not depend on WLAN or scenario 2 in any way, so the VPN tunnel can be established over any access technology. The VPN tunnel is very similar to the tunnel used in UMA, as described above.